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I. ISTRODOCTIDJI 



A. OBJECTIVES OF SESEABCEI 

The objective of the Stock Poiat Logistics Integrarai 
CoBmunica tions Environaient (SPLICE) Lccal Area ^Jetwcrk (LAN) 
Project at the Naval Postgraduate 3caool, Mcnrarey, was co 
develop alternatives for SPLICE LANs. The thesis subait-ea 
by Lieutenant Joesph N. Reinhart III, USMC and Lieutenant 
Ricardo Arana, Peruvian Navy [Ref. 1], concernea itself with 
the development of functional desiga specifications for the 
implementation of the Dataoase and Terminal Management func- 
tions of a functionally iistributed LAN in response to the 
requirements of the -Naval Supply System's stccc points and 
inventory control points. 

The objectives of this thesis research is to further 
define the requirements of the SPLICE users and to develop 
from these needs a generic model of Terminal Management (TM| 
functions necessary to support the services required. The 
rationale for using a generic model rather than a specific 
model lies in the evolutionary state of Naval Supply Systems 
Command (NAVSUP) data processing objectives. In an execu- 
tive level briefing, the SPLICE project office stated : 

'.^e cannot afford the luxury of supporting "Navy unique" 
software packages (in the" future) . Ne simoxy cannot 
afford the resource draw (drain). Our policy. must not 
allow unique solutions. Our systens must frt within the 
technoloav and capabilities or tae general ADP market- 
place. [Ref. 2] 

In keeping with that policy, this thesis will attempt to 
recommend, using the Reinhart and Arana thesis as a theoret- 
ical foundation, a TM functional specification capable of 
supporting presently envisioned SPLICE LAN configurations, 
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support 



svolutioneLry 



while prsseQtiug the rapabilitv 
cca figurations of the future. 

B. BiCKGROaND 

SPLICE/ as concievea by NAV3U? 
system to provide badly leeded lar 
communication and management function 
loiding the present hcst system, 
conceptual foundation for response tc 
customer requirements and technoLn; 
draws together under one conceptual 
new applications being developed in 
the supply shore est ablishn ent. 

SPLICE, in its simplest fora, i 
hardware and software arcnitecturs c 
wide variety of interactive applies 
local and remote terminals. «hen fu 
bility will significantly reduce the 
alone computers at support sites pre 
data processing services otherwise. 

Significant factors wiich will d 
the SPLICE concept will be the spee 
and file transfers within and betwe 
accuracy and ease of interactive ter 
the latter concern which is the reaso 

NA7S0? and Fleet Xaterial Support 
tation provide detailed informatio 
design considerations [Ref. 3], 
[Ref. 4], functional design [Ref. 5], 
plans [Ref. 6]. References 7 and 3 p 
magnitude and variety of transaction 
applications which SPLICE will be esc 
the LAN design project, with w 



describes a near-term 
al and svstem networ’'C 
s without further cver- 
It also presents the 
future Changes to both 
real advances. SPLICE 
umbrella tne myriad of 
d e pendently th rough out 

s designed to provide a 
apable of supporting a 
tion programs on both 
liy realized this capa- 
prolif eration of stand 
sentiy unable to obtain 



at ermine the success of 
d and accuracy of data 
en LANs and tne spee 
minal sessions. It is 
n for this thesis. 

Office SPLICE documen- 
n on SPLICE software 
systems specifications 
and teleco mmun ciations 
revide insight into the 
s contained in typicial 
pected tc support. As 
hich this thesis is 
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as3oci=-ed, is not ooistrained by SPLICE designs and 
spa Cl f icannons, nhe above references were used primarily as 
a source of purpose and oojecrives. Reference 1 provides a 
very readable synopsis of References 3 -hrough 5 . Readers 
desiring such information are referred to sections lA and 13 
of that document. In keeping with the objective of their 
research, Reinhart and Arana presented rheir recommendations 
for Database and Terminal Managemenc functional specifica- 
tions in support of a LA^ . In me name of brevity, a 
lengthy condensation of that thesis will not. be provided in 
this thesis. Instead, as this thesis uses the Reinhart and 
Arana thesis as a jumping-off point, later developments 
and/or information that night modify that thesis will be 
presented in section C of this introduction. 

Additional insights into the variety and size of the 
tasks expected to be processed on the SPLICE LAtl were gained 
by personal contacts with persons attached to the SPLICE 
project office at NAVSI? headquarters in Washington, D.C. 
and functional managers at Naval Supply Centers in Oakland 
and San Diego, The intent of this thesis, and therefore 
these interviews, was to establish in the author's mind a 
generic definition of interactive processing reguirements so 
that Terminal Management (TM) alternatives might be evalu- 
ated. The results of these investigative interviews are 
contained in Chapter II of this thesis. 

C. ADDENDUM TO REINHART AND ARANA THESIS 

In their background section, Reinnart and Arana implied 
that a commerical product named Terminal Application 
Processing System (TAPS) was the most probable implementa- 
tion of terminal management, database management, complex 
management, and transport management functions. At the 
time, that was a valid assumption and shared by NAVSDP. 
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Actual responses have shorfn that a significaar number of 
vendors responding the the SPLICE salicitation prefer their 
own functional modules to TAPS and are bidding accordingly. 
This acxion would appear to supporr Reinhart and Arana's 
contention that a functionally distributed LAM wirhout a 
central complex manager is viable. 

Section ID of the thesis discusses SPLICE functional 
implementation and provides a diagram in its Figure 1.3 of a 
possible implementaxion. An updated version of that diagram 
is contained in Reference 9 and Figure 1.1 below. 



Operotlng functions 




(Memory Module) Ofai or y Hbduld) 




9: p.4-6] 
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Figure 1 . 1 Possible Logical LAN Connections. 
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Also discussei in s=:tioi ID Df Reference 1 are t.h 
relative aerits of a high level iatabase query lancuag 
versus the interactive agplicatioi programs approach o 
NAVSUP. The thesis implies that NAVSU? shouli, and chere 
fore has yet to, investigate the feasibility nf a dacabas 
query language capability within SPLICE. This author' 
interviews and a review of NA730P policy guidance indicat 
that NAVSUP has the eventual development and use of such 
query language high on their AD? priority list. 
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II. RE20IRBMENrS DEFINITION 



A. OVERVIEW 

The methoi employed in attempting to arrive at a 
requirements definition for the Terminal Management (TM) 
function was a series of interviews using standard ques- 
tions. The interviews ware ocnduoted wi~h persons at -he 
Naval Supply Centers at Oakland and San Diego. These 
centers were chosen primarily because of locale, but this 
choice does not diminish the ef f ectiveness of the inner- 
views. Between them, San Diego and Oakland, conduct the 
entire range of stock point operations, with the exception 
of strategic forces support. San Diego supports a major 

fleet presence, a large training oommand, two major air 
stations, and numerous snore maintenance and administrative 
commands. Oakland supports a smaller fleet presence, one 
air station, fewer shore establishments, but serves as a 
clearing house for Western Pacific requirements. Both 

centers presently support remote terminal operations. Both 
have implemented either or both IDA or/and APADE to varying 
degrees. These terminal based interactive application 
programs are currently executed on stand-alone minicompu- 
ters, but their mere existence allows the functional 
managers using them to answer questions not answerable by 
managers without experience with this type of approach. 

The impressions gariered from these interviews are 

contained in section B below. Section C discusses informa- 

tion gained in meetings with NAVSUP SPLICE project office 
personnel. Section D sumnari2es the user requirements and 
associated assumptions that will oe used throughout the 
remainder of this thesis in evaluating TM approaches. 
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B. STOCK POINT EEQOIRESEHTS 



Interviews with srork point functional managers quickly 
established the presence of manageriil difficulties sxpsctei 
in trying to hold together an ongoing production efforr 
based on esrablished procedures and technology while trying 
to simultaneously implement a newer technology. Despite 
their rr ibulat i cns , these managers ware most willing to 
share rheir experiences to date with terminal based interac- 
tive application programs. 

Both IDA and APADE are designed :o utilize a menu-driven 
form mode of interactive data entry and fils inquiry/update. 
Both have extensive process options available co the 
terminal user. 

The APADE users, primarily in the purchasing division of 
the Procurement Department, logically and physically sepa- 
rate data entry functions from data inquiry/update 
functions. This is based mostly upon time constraints of 
data entry and the volume of these transactions. The TM 
implications of this separation is that the data entry 
clerks would be best served by the least creative, least 
complicated T.'l that would still support interactive form 
data entry, i. e., when finished with one form, the user 
wants another form immediately, not a helpful but neverthe- 
less key-stroke consuming menu. Di the other hand their 
co-workers who are responsible for handling a rather large 
number of document inquiries frcm not always patient 

customers would find the ability to split their screen into 
multiple sections and to conduct a separate inquiry or 
update in each section very helpful. The purcnasing admin- 
istrative personnel are freguently asked to produce 
information (written and oral) that requires multiple access 
to files and/or manual manipulation of the data accessed. 
The primary ca 'use of their effort is that they are 
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cons-rained by the fomats, both display and reporos, 
designed inro the systam. The oipability to design a 
multiple-use soreen and fornat at -he terminal is 

indicated. 

The IDA users, financial accounting, commonly referred 
to as Triple-A , do not separate their dara entry from 
inquiry/updare. Each clerk who has a rerminal has often 
foand himself in the situation of needing to view a record 
from more then one file. This situation is especially preva- 
lent when reconciling vendor invoices with requisitions. 
This need is presently met by calling a clerk who has access 
to the necessary files (APADE or (JADPS) ani passing the 
necessary information by oaone — ainomation indeed! 

The Customer Services personnel primarily inrerface with 
The UADPS applications residing on :he Burroughs hose main- 
frame, Their interaction with the computer is varied, bur 
basically inquiry in nature. Dana enrry is normally batch- 
processed, and will in all likelihood remain so until OCR 
technology replaces the current card readers. Because most 
queries are made to records stored and processed in 30 
column card format, a scroll-mods terminal presentation with 
the ability zo continually enter queries and direct replies 
to a nearby printer is the near concensus choice for 
terminal interaction. A less frequent activity conducted by 
Customer Services personnel requires them to spend hours 
researching and cross referencing records from various UADPS 
and financial files (now IDA files! • This reassarch is 
normally conducted by the most experienced and senior clerks 
and supervisors in the division, so it would seem that 
countless hours could be saved, not to mention dollars, if 
these persons could break away from the standard displays to 
which they are now limited and set up a screen display 
suitable for researching and controlling tne source of 
display input. 
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In wareho usi r.g anc natarial rscaipt functions, nhs uss 
of au^OEation has just begun, primarily in srowacs ant 
fstmsval oparatnons. lie day of tie use of ban codes ant 
light pens fon receipt processing and invenrory nanagenent 
ts stall soEswhat dnstant. Although there is good reason to 
suspect that these devices should bs considered oerioherals 



and therefore not within the 



purview of this ones is, tne 
author can envision a scenario where they would be direct 
input devices to several DADP5 aopiioation prograns. is 
such, the author has chosen to include then in 






oz potential terminals. 



C. NAVSO? POLICY iHD DISECTIOS 

In addition to a survey of stork; point personnel, a trio 
was aade to Washington, D.C. to aeet with 5PLICE project 
office personnel. The objective of the meetings was to gain 
an appreciation for the direction of 3PLICZ LAN’s. Although 
the development of a generic Th model from requirement needs 
is deemed academically justifiable, there remained the 
concern that to stray too far from the realities of the 
Naval Supply Systen would result in an academic exercise of 
little import. The quotation cited in Chapter I, Oojectives 
of Hesearch section, convinced this aurhor that such a model 
could in fact be of use, particularly in view of the desire 
to move away from "Navy unique" software. The functional TN 
model presented in Chapter 17 represents the autnor's desire 
to produce a recommendation for the near future, and there- 
fore embraces the reality of the 3PLICZ environment more 
than the generic TM model presented in Chapter CII. 

Addi-ionai information gained from tnese meetings 
included familiarization with the long-term oojectives of 
SPLICZ implementation. Although tnese objectives do not fit 
the category of user requirements, tiey are parupnased below 
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b93ause rdilurs to keep them in iiiini in a Issijr. orccass 
increases the probabnlnty that the resultant design nav too 
restrictive to be of value in meeting future growth. 

NAVSUP SPLICE Prolitt Dbiiltivis 

Data must be made available to the customer, easily 
accessed from wherever tie customer is located on a conti- 
nuous basis around the clock. 

- A distributed data base must be developed. 

G oal s for NA VSUP AD? 

All punched cards must be eliminated. 

- The use of point-of-sale terminals and hand held 
terminals with optical scanniag capabilities at data entry 
points. 

The use of bar codes and magnetic strips in inventory 
control and warehousing applications. 

D. COBCLOSIOHS AND ASSaHPPIONS 

The following conclusions regarding the TM requirements 
of users of the SPLICE LAN are based upon the interviews 
discussed above and observations of terminal use at stock 
points. Assumptions are based upon the same observations 
coupled with the author’s experience in stock point 
ops rations. 

1. A TH must be able to support a wide variety of termi- 
nals, varied not only in aake/modsL, but also in operational 
char acter istics . 

2. A TN must be able to support character, line, ps.gs, 
scroll, and form mode editing capabilites at the same 
terminal. 

3. A TM should provide the ability for a user to locally 
format a display area, and resultant hardcopy output. 
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4. A user should bs able to si multansousl y display 
multiple processes uriliziig diffsreit application programs. 

5. A TM should provide the mechanism to allow applica- 
tion to application interaction (author's assumption) 

6. A TH should be able to support non-interactive data 

entry, such as light pans and hand-held DCR (author's 

assumption) . 

7. A TM should provide a general framework within which 
future terminal functions can be accomodated (aurhor's 
assumption) . 

8. A TM design must recognize the relative lack of 
sophistication cf potential users and the probability of 
high turnover in these positions. 
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III. ASPECTS DP TERMINAL MANAGEMENT 



A. OVERVIEW 

In addition to the user reguirements iiscussed in 
Cha.pT.er II, investigation and evaijition of alterr.aTive TM 
techniques requires an appreciation for The technical 
concerns of a TM. Section B discusses these concerns. 
Section C outlines the LAN environoient assumed for This 
Thesis. Section D presents the author's view of a generic TM 
model. Section E then explores some of The TM approaches 
cited in contemporary literature. Section ? contains a 
review of the TM approach advocated by Reinhart and Arana 
[Ref. 1 ]. 

B. TM TECHNICAL CONCERNS 

TM, as a list of widely agreed to discrete functions and 
protocols, does not exisT. Rather, There exists an impres- 
sive, if somewhat confusing, spectrun of alternative methods 
of implementing a TM. Dn the most ambiTious end of this 
spectrum is a TM module iihLcb. provides the full range of 
funcTions described in the PresenTation Layer (layer 6) of 
the InTsrnational Standards Organization (ISO) Open Systems 
Int er conn ecTion (OSI) reference model. One of the many 
definitions of the task of the Presentation Layer "...is to 
support communications by providing commonly known virtual 
devices and commonly known virtual information to th= 
distributed applications" [Ref. 10: ?. 227]. A less ambi- 

tious TM would be expected only to "hide terminal 
idiosyncracies from the application programs" [Ref. 11; p. 
484]. The latter representing a subset of the former. 
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-slpiul ~o try tD describe the desirr. ccr.cerr.s of 
a ra and then to blend thsse concerns with user requirements 
to fern a model of the ideal or generic Th which would 
recognize both the designer's and user's concerns. 

A suggested list of concerns of the It designer is 
found in Reference 12 (op. 52-34). These concerns are: 

"* ) Cen trol of the Terninai Kandling - Assuninc the wide 
variety of terminals and attendant /ariety cf characteris- 
t.ics, the parameters which affect local handling cf a 
terminal must be known to the Hii, and to no other Lr.> module 
nor to remote users. 



2) should provide methods for 
selecting/prcvid ing support for botu half-duplex or full- 
duplex operations. 

3) Ter minal ^ta Strgpture - Like terminal control char- 
acteristics, the ?M must be aware of the data structure 
parameters of the terminal as well as the command language 
primitives available for manipulation of that structure. 

4) Symmet'v - The design cf the Th must be concerned 
with the desirability of symmetrical forms of connection, 
e.g. process-process and terminal-terminal interactions 

5) ~ must provide a dynamic 
mechanism to negotiate the facilities and parameters to be 
used in each interconnection. 

6) A11sL 2=2“§ “ must be capable of inter prettino 
ant handling the variety of methods used in terminals and 
processes to signal "brea^", "abort", and other such atten- 
tion commands. These signals are normally expedited signals 
"cut-cf-band" or outside tie tormal flow of data. 
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C- LOCAL AREA NETWORK (LAS) ENVIRON3ENT 

The LAN environment ii which the IN being discussed in 
this thesis will operate is a fully distributed LAN based 
upon seven primary functional software modules; local commu- 
nications, national conraaa ications, front-end processing, 
session services, terminal management, database management, 
and peripheral management. Figure 1.1 introduced the logical 
connections of this LAN. Figure 3. 1 presents a possible 
physical connection configuration. 
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Figure 3. 1 Possible Physical LAN Connections. 
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This t-hesis also assunss a multiplexed data/conerol Dus 
capable of supporting half and full-duplex communications. 
Further, it is assumsd that the terminals connected or 
potentially connectabls to this LA5T are hetrogsneous and 
that the hetrogenous mix iflll be in a constant state of flux 
during the next decade. 

D. GENERIC TH MODEL 

Given the user requirements, design concerns, and envi- 
ronmental assumptions developed above. Figure 3.2 presents 
the author’s attempt to meet these oriteria with a generic 
TM model. 




Figure 3.2 Generic Terminal Uanagement Model. 
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Figure 3.2 has the following componenrs; 

1) generic teminal with an input capibilit'/ 
(keyboard, light pen, optical scanner, etc.) ani an optional 
output device (CRT screen, signal lighr, teletype, etc.). 

2) A device or module which cat understand the signals 
coming from the input device and can send signals no nhe 
output device which it cai recognize. This component also 
has a command language of its own which allows the user to 
design an output display and to map note than one process to 
that display. 

3) This component represents the rerminal in dealings 
with the application process (one per process). It also 
builds and manipulates a terminal data structure for each 
process. 

4) This component represents the application program in 
dealings with the terminal process (one per process). It 
also builds and manipulates an application data structure 
for each process. 

5) This component sets the rules for and format of 
communications between the terminal processes and applica- 
tion processes (for all processes). 

In the most simplistic terms components 3 and 4 are 
attorneys for their clients, the terminal and the applica- 
tion program, respectively. They, and only they, know their 
clients capabilities and expectations. Both are very srrong 
willed and therefore need an arbitrator (component 5) to 
ensure that communicatins are meaningful and properly 
coo rdinated . 

At this point this model simply provides an ideal T!1 
whose generic components, if implemented ideally, would 
provide a modular TM capable of meeting user requirements 
and design concerns while having the flexibility to respond 
to changes. A recommended specific implementation of this 
model will be presented in Chapter IV. 
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E. TERMINAL HANAGEBENT APPROACHES 

Approaches to TM can be gsQscilly discussed ic two 
broad, and unfortunately act mutually exclusive, cacagoriss; 
parametric and virtual terminal. 

1, P ara m et r ic A£Drcacies 

Generally, parametric terminal protocols atrempt to 
list a set of terminal charac teristics with each cype of 
rermmal having a differeat set of parameters for each char* 
acterisric. The host, computer may then set tae parameters 
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[Ref. 13: pp. 335-348], [Ref. 14: pp. 586-587 ]. 

The PAD cited in CCITT protocols is the most compre- 
hensively defined parametric approaca to terminal handling. 
There are three basic approved reco mmeniations covering 
operation of the PAD; X. 3 which defines the PAD itself, X. 23 
defines the interface between the terminal and the PAD, ana 
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X.29 defines the intecfare between the PAD and rhe 
[Ref. 12; pp. 84-86 ]. 

The shortcoming of these approaches is that the PAD 
protocols provide no generic functions. They assume that 
the application in the host knows what the terninal will do 
and that the terminal will do what is intended [Ref. 14; 
pp. 586-587 ]. 

Telenet* s Interactive Terninal Interface (ITI) 
provides an enhanced set of parameters which helps offload 
some of the terminal handling responsibilities from the 
host. Telenet offers a farther refinement called a virtual 
terminal which includes a few generic functions on top of 
the ITI parameters. Jnf o rtunately, the ARPANET virtual 

terminal was designed primarily to support scroll-type 
terminals which have much fewer parameters than more 
sophisticated page and form mode terminals. Although the 
list of parameters was extended, few of the options (parame- 
tric values) were implemented [Ref. 14: pp. 586-587]. 

Both these approaches are most suitable for 
providing TM for existing terminals, the more homogenity the 
better. To be really useful, these functions should be 
standardized so that the host system can rely upon a 
PAD/inter f ace with known properties. Even with standariza- 
tion the envolvement of the host system in TM would still be 
extensive or the list of ? AD/interf ace parameters would be 
enormous [Ref. 13; pp. 347-348]. 

As several of the user requirements and design 
concerns discussed earlier imply the need for the greatest 
amount of transparency achievable and further imply an 
increasing number and variety of terminals, the parametric 
approaches appear too limited. 
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2* Vir tu al Tsrminal Pro+crDil 

Virtual Terminal Protocols (VTP) have undergone 
significant evolution since the first VT? was placed in use 
by the ARP ANET • This ?TP was designed primarily with 
scroll-mode terminals in mind. It. is based upon three basic 
principles; the concept of a 'networlc virtual terminal*, the 
concept of negotiation of options, and a symmetrical view of 
terminals and processes [Ref. 12: p. 38] [Ref. lit; p. 588]. 
This first VTP laid very firm ground for further sophistica- 
tion of the Virtual Terminal (VT) . iln f ortunat ely , although 
the Telenet VIP was designed with fifty-“ight parameters, 
very few were actually implemented. It therefore remains to 
explore a few more of the many VTP approaches developed 
since the ARPANET VTP. 

A model which focuses on page and fora mode termi- 
nals was developed by Schicker and Ouenki. It is used in the 
European Informatics Network (EIN) and is described in 
Reference 15 (p. 485). This model is called a data struc- 
ture model. In it a data structure is viewed as containing 

a set of fields each of which has certain attributes such as 
size of the field, what type of characters it contains, 
whether or not the field can be modified by the user, etc. 
This definition of a data structure has become widely 
accepted and will be used in the remainder cf this thesis. 
This model assumes that application programs are written to 
perform abstract operations on a data structure and that the 
remote (user) process has a similar data structure. The VT? 
is the mechanism by which the changes made by the applica- 
tion process to its data structure are passed to the user 

process so that its data structure can be changed accord- 

ingly, and vice versa. 
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A rsfinement of ths data structure model is 
described in Reference 13 ( pp. 362-355). la this model a 
terminal has a data structure aad a controlling process 
called a "T-PAD" with a relationship much like that 
described in the parametric approach in subsection 1 of this 
section. Similarly, the host system has a data structure 
with which it is designed to interact via a concrolling 
process called an "S-PAD" . The messages passed between 
these two "PADs" to negotiate the data structure and the 
available commands to manipulate the data structure are 
contained in the VTP. Tae appeal of this approach is two- 
fold; the S-PAD implies a NVT concept such as described by 
Tanenbaum in Reference 15 (p. 423) , where a NVT is an 

abstract terminal the characteristics of which are assumed 
by all interactive application programs; secondly, a symme- 
rrical approach such as rhis allows not only the tradi-ional 
terminal to application interaction, but also terminal to 
terminal and application to application interaction, given a 
sufficiently adept VTP. The utility of such capabilities 
can be shown in a common Stock Point scenario. This scen- 
ario exists when an application program, such as APADE, 
creates records that are duplicared or entered into files 
necessary to the correct operation of another application 
program, such as IDA. For instance, the i=stablishment of a 
contract, which requires a record update in an APADE file, 
also necessitares an update of a financial record in an IDA 
file. Such changes can be made by batch processing (current 
practice) or by application to application interaction such 
as made possible by a TM implementing this type of model. 

The approach above is very similar in function, if 
not vocabulary, to the NVT envisioned for ARPANET'S Telenet 
protocol and the INWG VTP. All are deemed symmetrical in 
that each side of a session has its own view of ths state of 
the VT 1 P» 5 89]. Tais as opposed to an 
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asymmetrical model where the VI is considered only from the 
perspective of the application program. In such a model the 
physical terminal is transformed by software to appear as a 
VT to the application program [Rsf, 16: p. 304]. This 

approach cannot support terminal to terminal or process to 
process interaction [Bef. 14; p. 588]. 

In each of the 7T concepts described the VT’s are 
supported by two elementary protocols; a virtual terminal 
display data transformation protocol and a control protocol. 
The data transformation protocol maps display commands from 
the sending process into the prescribed input data formats 
for the receiving process. The coatrol process exchanges 
non-display information for coordinating interactions 
[Bef. 17: p. 85]. 

A more expansive approach is offered in Reference 
10. In this approach three abstractions (virtualisations) 
are proposed; a virtual device, a conceptual data “Ype 
definticn, and a conceptual image. The virtual device is 
considered an association between a definition of a struc- 
ture for a (device) data object and a set of operations 
which are the only means for accessing this (device) data 
object. The conceptual data type definition is a similar 
association, but with regard to the structure of data and 
the operations which may be pefocmed on data structure 
objects. The conceptual image is considered a definition of 
the means by which a mapping of the conceptual data on the 
virtual device is obtained. The thrust of this concept is 
that in a hetrogenous network, assumptions regarding inden- 
tical virtual devices and data structures may not be 
desireable and possibly not practically viable. Only an 

agreement of negotiated parameters need be known by each 
partner. The authors wrote a follow-on article, [Rsf. 18], 
in which they presented a detailed recommendation of the 
protocols and options for each of these virtualisations. 
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All of the above approaches require the nsgoriarions 
of options/parameters to be used Lq a sessiou, be *hey 
device charact eristics , data structure or comniands. 

Negotiations are either asynchronous or master-slave (synch- 
ronous) depending on the symmetry of the interaction and the 
trust the designers place in whate/er mechanism they may 
have implemented to resolve negotiation deadlocks. The 
literature regarding negotiaticn algorithms seems polarized 
vfith each side singing the praises af their approach. The 
author's preference is included in the TM model presented in 
Chapter IV. 

F. REINHART AND ARANA TM 

In Reference 1 (p. 55), the authors proposed a TM 

approach based upon a "Virtual Terminal" managsaent concept. 
The primary feature of their VT is that it "... converts a 
single physical terminal into multiple virtual terminals, 
each of which may be written into or queried for input". To 
support this concept the idea of a user defined screen 
configuration is proposed. This rfould allow a user to 
divide his screen into "windows" each of which contains the 
display of a separate process. Although only one window/ 
process would be active at a given moment, it is clear that 
the implementation of this concept would satisfy several of 
the requirements and concerns addressed earlier in this 
thesis. 

The thesis also discuss on page 7d the use of a generic 
terminal transformation taole. This table, as proposed by 
Hillsberg [Ref. 19] is used to convert specific physical 
terminal sub- fun ctions to generic commands and vice versa. 

Although this thesis owes its roots to the Reinhart and 
Arana effort, subsequent readings and investigation have led 
this author to step back from most of the specifics 
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IV. EE30HMENDAriDNS 



A. OVERVIEW 

The recommendations oontained in this chapter are a 
marriage of the generic T!1 model prasented and tha varist/ 
of specific approaches discussed in Chapter III. The result 
is a specific m cdel consisting of cnmponents and protocols 
interfacing those components. General recommendations are 
listed in section B below. Section C presents the recom- 
mended model. 

B. GENERAL RECOHHEHDATIONS 

1) The TM should be based upon the concept of a NVT. 
Each application program should be aole to assume that it is 
dealing with a terminal wnere the default parameters will be 
used unless the user negotiates different parameters using 
the NVT capability. 

2) The TM should support the highest level of abstrac- 
tion technologically available. 

3) Negotiation of device definitions should be hierarch- 
ical. Standard classes of Terminals defining mandatory 
characteristics (minimum parameter values) should reside at 
rhe highest levels of the hierarchy. Optional (negotiatible) 
operations should reside at lower le/els. 

4) The TM Should support user defined screen format for 
use in both displaying mulriple processes and designing 
display and possible report format. 
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C. RECOHMENDED TH HODEL 



Figure 4.1 presents the Tecilial Hanagecient. 'lodel. 
recommended by the author. The components are explained 
below. 




I 



Figure 4.1 Recoiaenied TM Model. 



1 • I np ut/Ou tou t Device 

A terminal is viewed as two separate devices. The 
separation recognizes chat a LAN may recieve input from 
devices that have no outpat capability, e.g. light pens, OCR 
scanners, etc. The TM must be able to handle inputs from 
such devices. Additionally, the ability to transform and 
control inputs is conceived to be totally separated from the 
ability to control and map output. 
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2. Local Virtual lirDinal (LVT) 

/ 

The function of the LVr is to hide the idiosychra- 
cies of the user terminal from the LAN and to map irs data 
structure and any changes to that structure to the terminal 
display device. The LVI consists of a terminal process (T?) 
component and a disk-based terminal data structure (TDS). 

The TP utilizes a generic terminal transformation 
table (see Ref IS) to virtualize terminal sub-functions and 
a hierarchically organized set of terminal primitives and 
parameters as discussed in paragraph B.3 above. The TP also 
uses a user defined map of the screen display for output. 

The TP is responsible for representing the terminal 
in negotiations with the application process (or another 
TP) . It is also responsible for mapping terminal input 
commands to the TDS and for mapping TDS changes to the 
output unit. These functions are comparable to the "T-PAD" 
discussed in Reference 13 and Chapter III. 

3* Ne t wo rk Virtual Terminal (NVF) 

The NVT is configured identically to the LVT with an 
application process (AP) in place of the TP. The AP has the 
same data structure modifications responsibilities, except 
that it takes orders from and reports changes to an applica- 
tion program as opposed to a terminal. 

The major conceptua 1 difference between the NVT and 
the LVT is that the NVT is a parametric model of the entire 
network's concept of a terminal. Its primitives and parame- 
ters are fixed. The application program's requirements are 
met by passing necessary parameter values to the AF. Note 
that the number of parameters are fixed, but that each 
parameter may offer more than one option (value). The A? 
then represents the application program in negotiations with 
the T? as to what values will actually be used. Obviously, 
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tha AP will not agree to any parametric values lower chan 
the program requires, but it may agree to higher values 
should the TP insist. The AP hides all negotiatied values 
from the program except those that tie program expects. 

V irtu al Terminal Protocol (VTP) 

The VTP is a message based protocol with several 
functions, discussed here in chronological order. The VIP 
controls the the exchange of negotiation messages between 
the TP and AP. During these negotiations the primitives and 
parameter values of control messages are selected as well as 
the contents of the data structure. The recommended negoti- 
ation protocol will be explained In the session example 
below. Cnee all values are set, the VTP becomes responsible 
for passing control messages between the TP and AP for the 
manipulation of their respective data structures. In 
fulfilling this responsibility, the VTP controls the 
sequencing of messages according to the communication method 
selected during negotiations, i.e., alternating or free- 
running, and dictates the format of these messages. 

5 . Session Example 

a) The user logs on his terminal identifying himself 
and the terminal ID. Terminal ID can be done automatically 
if the capability exists. 

b) The TP will compute the command signals needed to 
handle this particular terminal using the transformation 
table. The TP will then begin a screen formatting subroutine 
conversation with the user, in which the first user response 
may result in a default screen. (note; asking the question 
rather than waiting for the user to request screen format- 
ting should evoke curiosity and guicxen the learning process 
for this feature) This routine will construct the output map 
for the TP's subsequent interaction with the output device. 






c) Once the assr has defined the screen fcrniat 
desired, the first (and possibly only) command no call an 
application program is entered. 

d) The TP passes this message to the LAM which may 
need to send it out to the long-haul network. 

e) The destination node will establish an AP to 
which the application program passes its terminal and data 
structure requirements. At this point, and throughout the 
negotiation process, the VTP is ensuring one-way 
com munications. 

f) Once negotiations have been completed, the appli- 
cation program directs the A? to set the initial state of 
its data structure. Upon doing so, the AP, using the VTP 
message format, passes the agreed data structure instruc- 
tions TO the TP which both creates an idenrical initial 
state in its data structure and maps the data structure to 
the user-defined screen format. 

g) At this point the VTP may allow free-running 
(asychronous) communications if both parties can support 
such. 

h) When the application program is completed, rhe 
ccnnecticn is severed and the TP begins its user dialouge 
ane w. 

Admittedly, this TM model is a compromise between 
the generic goals presented in Chapter III and the pracrical 
implications of NAVSOP's dedication to application programs. 
A more esthetically pleasing concept is outlined in Chapter 

V. 
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V. THE REZDMMENDED aPPROACH 



a. THE aSSDHPTIONS 

The concept discussed in this chapner is a recoramenda- 



tion for the 


future. 


It is based 


on ths following 


assumptions : 








1) KA7SUP 


is willing 


to abandon the 


development and use 


of application 


programs in 


favor of funct 


ional modules and a 



disrributed database sysren . 

2) NA7S0P defines nha set of queries and reporns it 
wishes the system to provide. 

3) NA7S0P is willing to allow increased local flexi- 
bility in the design of display and report formats. 

B. THE CONCEPT 

Given the above assumptions, tae envisioned data base 
system would be built by use of a dita base "designer" and 
program generator such as discussed in Reference 20 . The 
basic tool of this building process is called a Hierarchical 



Interact 


i ve Quer y 


(HI-IQ) language. 


The result 


of this 


process 


would be a 


database capable 


of supporting 


programs 


written 


in a COBOL 


Data Manipulation 


Language (DHL) 


for data 



entry and inquiry. The primary charm of this concept is the 
reduction of redundant record fields in different applica- 
tion files and the concomitant reduction in required fils 
space. Given that there are only two primary fields forming 
the backbone of the vast majority oC stock point and inven- 
tory control point transactions, the requisition number 
(order number) and the National Stock Number (or part 
number) , the concept of a hierarchical data base system to 
support what is now supported by HADPS fils management 
programs is not so far-fetched. 
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A second enhancement this approach offers is -he elimi- 
nation of the need for applioation to application- 
interaction, be it batch or interaotive. Because the finan- 
cial data field for a tJADPS requisition entry is the same 
field used in IDA, the need for passing this information to 
the IDA application prograa for entry is eliminated. 

C. TH IHPLICATIOHS 

Adoption of the systen described above would not neces- 
sitate scraping the TS recommended in Chapter IV, but to 
fully capitalize on the benefits of the system, certain 
changes would be necessary. 

The most important change would be to enhance the 
Terminal Process (IP) by providing it with a data structure 
description language whicn would logically be a subset of 
the system's Data Manipulation Language (DHL). This 
language would be available to a user to name fields and 
zones and for defining the attributes and dimensions of 
such. This capability would enable users to easily dssign 
screen and report formats tailored to their needs. But, such 
a capability would require a rethinicing of the application 
program's master role in establishing data structure 
parameters. 

As this concept would move away from the application 
emphasis on form or page designs in data structures, changes 
would also be necessary in NVT and VIP parameters. Both 
could be simplified because they would not have to be struc- 
tured to support a myriad of often conflicting application 
programs. 

Should the assumptions in section A evolve , the concept 
outlined in this chapter is strongly recommended for further 
study. 
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